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Timed Transition Models (TTMs) are event-based descriptions for modelling, specifying, and veri¬ 
fying discrete real-time systems. An event can be spontaneous, fair, or timed with specified bounds. 
TTMs have a textual syntax, an operational semantics, and an automated tool supporting linear-time 
temporal logic. We extend TTMs and its tool with two novel modelling features for writing high-level 
specifications: indexed events and synchronous events. Indexed events allow for concise description 
of behaviour common to a set of actors. The indexing construct allows us to select a specific actor 
and to specify a temporal property for that actor. We use indexed events to validate the requirements 
of a train control system. Synchronous events allow developers to decompose simultaneous state up¬ 
dates into actions of separate events. To specify the intended data flow among synchronized actions, 
we use primed variables to reference the post-state (i.e., one resulted from taking the synchronized 
actions). The TTM tool automatically infers the data flow from synchronous events, and reports 
errors on inconsistencies due to circular data flow. We use synchronous events to validate part of 
the requirements of a nuclear shutdown system. In both case studies, we show how the new nota¬ 
tion facilitates the formal validation of system requirements, and use the TTM tool to verify safety, 
liveness, and real-time properties. 


1 Introduction 

Cyber-physical systems integrate computational systems (the “controller”) with physical processes (the 
“plant”). Such systems are found in areas as diverse as aerospace, automotive, energy, healthcare, man¬ 
ufacturing, transportation, and consumer appliances. A main challenge in developing cyber-physical 
systems is modelling the joint dynamics of computer controllers and the plant [1], 

Timed Transition Models (TTMs) are event-based descriptions for modelling, specifying, and veri¬ 
fying discrete real-time systems. A system is composed of module instances. Each module declares an 
interface and a list of events. An event can be spontaneous, fair, or timed (i.e., with lower and upper time 
bounds). In [6], we provided TTMs with a textual syntax, an operational semantics, and an automated 
tool, including an editor with type checking, a graphical simulator, and a verifier for linear-time temporal 
logic. So far, TTMs were used to verify that a variety of implementations satisfy their specifications. 

In this paper, we extend the TTM notation, semantics, and tool for two novel modelling features: 
indexed events and synchronous events. These constructs are suitable for writing high-level specification, 
and can thus facilitate the validation of system requirements. 

Indexed events allow for concise description of behaviour common to a (possibly unspecified) set of 
actors. The indexing construct allows us to select a specific actor (such as a train) and specify a temporal 
property for that actor. For example, let loc be an array of train locations (a train can be on either the 
entrance block, a platform, an exit block, or outside the station). An event move .out can be indexed with 
a set TRAIN of trains, which results in an indexed event move out(t: fair TRAIN) describing the action 
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of a train t moving out of a platform and into the exit block. As a result, the event index t can be used to 
specify the liveness property that every train t waiting at one of the platforms (denoted by the set PLF ) 
eventually moves out, and into the exit block: \3(loc[t] G PLF =$■ ()movej>ut(t)). Without the index t, 
we can only state a weaker property that some train eventually leaves the station (unless we introduce 
auxiliary variables or events). 

Synchronous events allow developers to decompose simultaneous state updates into actions of sep¬ 
arate events. However, without a mechanism to reference the post-state values of monitored variables, 
we cannot properly model the joint actions of the environment and controller. For example, the synchro¬ 
nized action m := exp || c :=/(m) specifies that the new (or next-state) value of controlled variable c 
is computed on the basis of the old (or pre-state) value of monitored variable m (i.e., exp). To resolve 
this, we use primed variables on the RHS of assignments in event actions to denote post-state values. For 
example, the synchronized action m := exp || c :=/ (in’) specifies that the post-state value of c is now 
a function on the post-value value of m. Synchronous events, together with primed variables, are suit¬ 
able for describing high-level specifications used in shutdown systems of nuclear reactors rill . In such 
systems, the next-state value of the system controlled variables are expressed in terms of the current- 
state and next-state values of the monitored variables of nuclear reactors. This allows for a simplified 
description of the requirements that will later be refined to code. 

Contributions. To support indexed and synchronous events for validating requirements, we extend the 
semantics of TTM (Sec. 2), and we extend our tool accordingly. For synchronous events, our tool 
automatically infers the data flow, and reports on inconsistencies due to circular data flow. We conduct 
two realistic case studies: a train control system (Sec. 3) using indexed events, and a part of a nuclear 
shutdown system (Sec. 4) using synchronous events. 

Resources. Complete details of the two case studies are included in an extended report 1101 . which also 
contains more case studies of cyber physical systems (i.e., a mutual exclusion protocol, and function 
blocks from the IEC 61131 Standard for programmable logic controllers) that can be specified using 
the new notations. Complete TTM listings of the case studies are available at: https://wiki .eecs. 
yorku.ca/proj ect/ttm/index_sync_evt. 


2 Semantics for Indexed and Synchronous Events 

We extend the one-step operational semantics of TTMs reported in [6] to support both indexed events 
(Sec. 2.2) and synchronous events (Sec. 2.3). The extensions involve redefining: 1) the abstract syntax 
of events which affects the rules of transitions and scheduling; and 2) the rules of module compositions. 
We include the most relevant details to present these extensions, while the complete account of the new 
semantics is included in an extended report [10, Sec. 6]. 

2.1 Abstract Syntax: Introducing Fair and Demonic Event Indices We define the abstract 
syntax of a TTM module instance as a 5-tuple (V,so, TJq.E) where 1) V is a set of local or interface 
variables; 2) T is a set of timers; 3) £ is a set of state-changing events; 4) so G STATE is the initial 
state (STATE = V -F VALUE); and 5) to G TIMER is the initial timer assignment (TIMER = T —> 
N). We define type G T —t P(N) and boundt G T —for querying about, respectively, the type and 
upper bound of each timer. For example, if timer t\ is declared as t\ : 0..5, then boundt(t\ ) = 5 and 
type{t\) = {0..6}. Timers count up to one beyond the specified bound, and remain unchanged until they 
are started again. The figure below presents the generic form of a TTM event, where V = {vi,V 2 ,V 3 , • • •} 
and T = {h,t 2 ,h,U, ■ ■ ■}. 
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Abstract syntax of the event e\ 

• e.id £ ID; 

• e.fJnd C ID ; e.dJnd C ID 

• e.dJnd = e.fJnd U dJnd 

• e.l £ N; e.u £ N U {°°} 
e.fair 

£ {spontaneous,just,compassionate} 

• e.grd £ STATE x TIMER ->• BOOL; 

• e.start C T ; 

• e.stop C T ; 

• e.action £ STATE x TIMER xx STATE; 

We use a 10-tuple (id, fJnd,d Jnd,l,u, fair,grd,start,stop,action) to define the abstract syntax of 
an event e. We write e.id for its identifier. Sets e.fJnd and e.dJnd contain, respectively, fair and demonic 
indices that can be referenced in the event. Its fairness assumption (i.e., e.fair), as discussed in Sec. 2.2, 
filters out certain execution traces that will be considered in the model checking process. Its guard (i.e., 
e.grd ) is a Boolean expression referencing state variables, timers, or its indices. An event e must be taken 
between its lower time bound (LTB) e.l and upper time bound (UTB) e.u, while its guard e.grd remains 
true. The event action involves simultaneous assignments to vi,V 2 , ■ ■ ■. We write V 3 :: 1..4 for a demonic 
(non-deterministic) assignment to V 3 from a finite range. Therefore, its state effect is a relation e.action 
on state variables and timers. On the RHS of an assignment y := x, the state variable x may be “primed” 
(x') or “unprimed”. A primed variable refers to its value at the next state, or its current-state value if it 
is unprimed. The use of primed variables in expressions allows for more expressive descriptions of state 
changes, especially when combined with the use of synchronous events (Sec. 2.3). 

2.2 Operational Semantics Given a TTM module instance , an LTS (Labelled Transition Sys¬ 
tem) is a 4-tuple 2 z? = (II, 7 ToiT, — f) where 1) n is a set of system configurations; 2) 7io £ n is an initial 
configuration; 3) T is a set of transitions names (defined below); and 4)—>CIIxTxnisa transition 
relation. 

We define Em as the set of event transition names, and Ef a i r as the set of transition name prefixes, 
excluding values of demonic indices (i.e., including values of fair indices): Em = {e,m \ e £ E A m £ 
e.fJnd —>•VALUE • (e.id.m)}. On the one hand, we use e(x) to denote the (external) transition name 
of event e with x, the values of its fair indices. On the other hand, when referring to the occurrence of e, 
in an LTL formula for instance, we use e(x,y ) to include y, the values of its demonic indices; otherwise, 
values of demonic indices are treated as internal non-deterministic choice within the event. 

A configuration n £ IT is defined by a 6 -tuple ( s,t,m,c,x,p ), where: 

• s £ STATE is a value assignment for all the variables of the system. The state can be read and changed 
by any transition corresponding to an event in E. 

• t £ TIMER is a timer valuation function. Event transitions may start, stop, and read timers. A tick 
transition representing a global clock changes the timers. 

• m£T —> BOOL records the status of monotonicity of each timer. Suppose event e\ starts t\ , then we 
may specify that a predicate p becomes true within 4 ticks after e\ ’s occurrence. However, other events 
might stop or restart t\ before p is satisfied, making t\ not in sync with the global clock. The expression 
m(t\) (monotonicity of timer t\) holds in any state where t \ is not stopped or reset. 


Concrete syntax of event e\ 

event Ad (x : fair T x \ y : T y ) [l,u] just 
when grd 
start t\,ti 
stop ?3, f 4 
do vi := exp \, 

if condition then V2 := Vj +exp2 

else skip fi, 

V 3 :: 1..4 
end 
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• c E E it [ H> N U {—1} is a value assignment for a clock implicitly associated with each event. These 
clocks are used to decide whether an event has been enabled for long enough ( c(e.id,x ) > e.l) and 
whether it is urgent ( c(e.id,x ) = e.u). 

• x E Ej ( j U {_L} provides a sequencing mechanism: each transition e is immediately preceded by a 
transition e# to update the monotonicity record m. 

• p E Ejd U {tick, _L} holds the name of the last event to be taken at each configuration. It is _L in the 
initial configuration. It allows us to refer to events in LTL formula, to state that they have just occurred. 

We focus on components s and c that are affected the most by fair and demonic indices, whereas 
components t, m, and x, as to how the monotonicity status of timers is maintained, are less relevant and 
included in 110. Sec. 6]. 

Given a flattened module instance .EE, transitions of its corresponding LTS are given as T = E id U 
E# U {tick}, where E# = {e E • e#} is the set of monotonicity-breaking transitions as mentioned 
above. Explicit timers and event (lower and upper) time bounds are described with respect to this tick 
transition. We define the enabling condition of event eGf with fair index x and demonic index y as when 
its guard is satisfied, and when its implicit clock is in-between its specified bounds: ( e.en(x) = (3y • 
e.grd(x,y )) A e.l < c(e.id,x) < e.u ). 

The initial configuration is defined as 7To = (so,to, m oEo,E,E), where .so and to come from the ab¬ 
stract (Sec. 2.1). The value of each event e,’s implicit clock depends on its guard being satisfied initially. 
More precisely, co(e,-./d,x) equals 0 (the clock starts) if (sodo) \= (3y • ej.grd(x,y)) 1 ', otherwise, it equals 
-1. 

Ti To 

An execution a of the LTS L is an infinite sequence Kq -E Tt\ yita-*■■■, alternating between config¬ 
urations Jti E IT and transitions T, E T. Below, we provide constraints on each one-step relation in %') 
in an execution. If an execution a satisfies all these constraints then we call a a legal execution. To 
characterize the complete behaviour of EE, we let £ % denote the set of all its legal executions. Given a 
temporal logic property <p and an LTS EE, we write E£\= (p iff Va £ I, • (j\= tp. There are two possible 
transition steps (event e(x) and tick): 


(s,t,m,c,e(x),p) e -$ (s',t',m',c',E,e(x)) (1) 

(s,t,m,c, E,p) ^ (s,t r ,m',c',E,tick) (2) 

Taking e The transition e(x) specified in Eq. 1 is taken only if the x-component of the configuration is 
e (meaning that e# was just taken, so e is the only event allowed to be taken) and ( s,t,c) 1= e.en(x). 
The component s' of the next configuration in an execution is determined non-deterministically by 
e.action(x,y), which is a relation as demonic indices or assignments may be used. Consequently, any 
next configuration that satisfies the relation can be part of a valid execution, i.e., s' is only constrained 
by (s,t,s') E e.action(x,y). The following function tables specify the updates to c upon occurrence of 
transition e(x). 


Lor each event cy E E, x E ty./ ind —> VALUE 

c' (ei.id) 

(s’,t’) ¥= ( 3 :v • e i-grd(x,y)) 

-1 

(s'/) 1= (3y • e i-grd(x,y )) 

(s,t) |= (3y • ei.grd(x,y )) A = d 

c(ei.id,x) 

(s,t) (3y • ei.grd(x,y)) V e t = e 

0 


1 If a state-formula q holds in a configuration n, then we write K 1= q. For formulas such as guards which do not depend on 
all components of a configuration, we drop some of its components on the left of f=, as in (sodo) 1= e -g r d(x,y). 
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We start and stop the implicit clock of e L as a consequence of executing e, according to whether ei.grd 
just becomes or remains false (1st row), remains true (2nd row), or just becomes true (3rd row). Event <?,- 
is ready to be taken if it becomes enabled ej.l units after its guard becomes true. 

Taking tick The tick transition specified in Eq. 2 is taken only if the x-component of the configuration is 
_L (thus preventing tick from intervening between any e# and e pair) and if Ve £ E • c(e.id.x) < e.u. 


For each event e £ E, x £ e.fJnd -£ VAFUE 

c'(e.id,x) 

{s',t') (3y • e.grd(x,y)) 

-1 

(s’f) \= (3y • e.grd (x,y)) 

(s,t) V 1 (3y • e.grd(x,y)) 

0 

(s,t) |= (3y • e.grd(x,y)) 

c(e.id,x ) +1 


Thus, tick increments timers and implicit clocks towards their upper bounds. 

Scheduling So far, we have constrained executions so that the state changes in controlled ways. However, 
to ensure that a given execution does not stop making progress, we need to assume fairness. The current 
TTM tool supports four possible scheduling assumptions. 

1. Spontaneous event. When no fairness keyword is given, and the UTB is given as * or unspecified, 
then even when the event is enabled, it might never be taken. 

2. Just event scheduling (a.k.a. weak fairness [9]). This is assumed when the event is declared with 

the keyword just and when the upper time bound is * or unspecified. For any execution if 

an event e eventually becomes continuously enabled, then it occurs infinitely many times: a 1= (Vjc • 
0 Oe.en(x) —> D0(3y • e(x,y))), where x ranges over e’s fair indices and y its demonic indices. 

This highlights the key distinction between fair and demonic indices. The fairness assumption guar¬ 
antees that e(x, _) is treated fairly for every single value of x. For example, if x is a process identifier, 
making it a fair index means that as long as it is active, each process is eventually given CPU time. In 
contrast, if x is treated as a demonic index, then it is possible that infinitely often the same process will 
be given CPU time. 

3. Compassionate event scheduling (a.k.a. strong fairness [9]). This is assumed when the event is 
declared with the keyword compassionate and when the upper time bound is * or unspecified. For any 
execution <7 £ if an event e becomes enabled infinitely many times, it has to occur infinitely many 
times. More precisely: a 1= (Vjc • □<> e.en(x) —> D0(3y • e(x,y)). 

4. Real-time event scheduling. The finite UTB e.u of the event e is taken as a deadline: it has to occur 
within u units of time after e.grd becomes true or after the last occurrence of e. To achieve this effect, 
the event e is treated as just. Since tick will not occur as long as e is urgent (i.e., e.c = e.u), transition e 
will be forced to occur (unless some other event occurs and disables it). 

2.3 Semantics of Module Composition So far we have specified the semantics of individual mod¬ 
ule instances. However, the TTM notation includes a composition. The semantics of systems comprising 
many instances is defined through flattening, i.e. by providing a single instance which, by definition, has 
the same semantics as the whole system. 

Instantiation When integrating modules in a system, they first have to be instantiated, meaning that the 
module interface variables must be linked to global variables of the system which it will be a part of. For 
example if we have a Phil module (for philosopher) with two shared variables, l eft .fork and right fork, 
and two global fork variables /1 and /2, we may instantiate them as: 
instances pi = /7n7(share/7, share f2 ); p2 = Phil(sharef2, share fl) end 

Philosopher pi is therefore equivalent to the module Phil with its references to left fork substituted by 
/1 and its references to right fork substituted by /2. 
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Composition The composition ml||m2 is an associative and commutative function on two module in¬ 
stances. To flatten the composition, we rename the local variables and events (by prepending the module 
instance name) so that they are system-wide unique. We then proceed to create the composite instance. 
Its local variables are the (disjoint) union of the local variables of the two instances. Its interface vari¬ 
ables are the (possibly non-disjoint) union of the interface variables of both instances with their mode 
(in, out, share) adjusted properly 110. Table 1, p. 38] (e.g., variable in x in ml and variable out x in 
m2 result in an out variable in the composite instance). 

The simplest case of composition results in the union of the set of events of both instances. However, 
events from separate instances can be executed synchronously. This can be specified using the notation of 
synchronous events. As an illustration, consider a case where the plant and controller act synchronously. 


module PLANT 
interface 
x : out INT = 0 
events 

generate 

do 

x :: 0 .. 10 

end 


module CONTROLLER 
depends p : PLANT 
interface 
x: in INT 

b : out BOOL = false 
events 

respond sync p.generate as act 

do 

if x’ > 0 then b := true else b = false fi 
end 


instances 

env = PLANT(out x) 
c = CONTROLLERS x, out b) 

with 

p := env 

end 

sync .env_c ::= env || c 

end 

composition 

system = sync env c 

end 


We say module CONTROLLER depends on module PLANT. At the module level (e.g., CTRL), we use a 
depends clause to specify a list of instances that the current module depends on. At the event level (e.g., 
respond), we use a sync ... as ... clause to specify the list of events to be synchronized, qualified by 
names of the dependent instances (e.g., p.generate), and to rename the synchronized events with a new 
name (act). Actions of events that are involved in synchronization may reference the primed version of 
input variables to obtain their next-state values. For example, the respond event uses the next-state value 
of the input variable x (i.e., x’) to compute the next-state value of its output variable b. In creating an 
instance, we use a with ... end clause to bind all its dependent instances, if any. We use the :.= operator 
to rename the synchronized instances (e.g., sync _env _c). As instances env and c are synchronized as the 
new instance sync-env-C, taking the event sync env c.act has the effect of updating, as one atomic step, 
the monitored variable x then controlled variable b. 

Specifying depends clauses (at the module level) and sync clauses (at the event level) results in one 
or more compound events whose actions are composed of those involved in the synchronization. We 
discuss the process of merging event actions below. For how event time bounds and fairness assumptions 
are merged in synchronization, refer to HO. p. 40]. 

The use of synchronous events results in three kinds of dependency graphs 2 . 

1. The Module Dependency Graph contains the set of vertices V = MOD, and the set of edges consisting 
of (m\, m 2 ), where module m\ depends on m 2 . 

In each connected component of the module dependency graph, we construct a synchronous event set 
(e.g., {PLANT.generate,CONTROLLER.respond }) by including each event e, where e declares a sync 
clause, and all events under e’s sync clause. 

2 Assume that MOD denotes the set of declared modules, EVT the set of declared events qualified by their containing 
modules, e.g., PLANT.generate, and VAR the set of interface and local variables 
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2. An Event Dependency Graph contains the set of vertices V = EVT, and the set of edges consisting of 
(ei, to), where e\ and to are in the same synchronous event set and to is declared under the sync clause 
of e\. 

3. An Action Graph is constructed from each synchronous event set. We write VAR S to denote variables 
that are involved in actions of events in a synchronous event set s. For each synchronous event set s, its 
corresponding action graph contains the set of vertices V = VAR S , and the set of edges consisting of (v i, 
V2), where the computation of Vi’s new (or next state) value depends on that of V2- There are two cases 
to consider: 1) in an equation where V 2 appeal's on the RHS and v\ ’ on the LHS (i.e., vi ’ = ... V 2 ...); 
and 2) in an assignment where V 2 appears on the RHS and v\ on the LHS (i.e., vi := ... V 2 ...). 

We perform a topological sort on each action graph to calculate the order of variable assignments, 
from which we calculate a sequence of variable projections. The projection for each variable v is a pair 
(v,act), where act is either an unconditional assignment (i.e., v := exp), or an conditional assignment 
(i.e., if b\ then v := exp\ elseif Z?2 then v := exp 2 ... else ...). The latter case is resulted from the fact 
that changes on v (either through assignments or the primed notation) occur inside nested if-statements. 
Finally, the produced sequence of variable projections is adopted as the action of the compound event. 

To ensure consistency, the TTM tool reports an error when, e.g., one of the above graphs contains a 
cycle, or a flattened (or compound) event assigns multiples values to the same variable. 

Iterated Composition. Iterated composition allows us to compose an indexed set of similar instances. 
For example, in the case of a network of processes, we may specify the common process behaviour 
as a module once, and instantiate them from the set PID of process identifiers: system = || pid : 
FID @ Process (in pid). 


3 Example: A Train Control System 

We illustrate the use of TTM indexed events in a train control system. There are two reasons for using 
the indexed events. First, all trains entering and leaving the station share a common behaviour. Second, 
by declaring event indices (ranging over trains) as fair, we can assert that individual trains arriving at the 
station are guaranteed to depart, without being blocked indefinitely by other trains. 


SIGNALS 




ENTRY PLATFORM EXIT 




moveout (t) 

when outgoing signal is green 


move in ( t ) 

when incoming signal is green 



(a) Topology (b) State Transitions of Train t € TRAIN 

Figure 1: A Train Control System 

Fig. la shows the topology of the train control system [3J. There is an entry block ( Entr ) and an exit 
block (Exit) on both ends of the station. Between the entry and exit blocks is a set PLF of special blocks 
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called platforms. At most one train may stay at the entry or exit block at a time. On the entry bock, 
there is a signal isgn regulating the incoming train, depending on the availability of platforms. On each 
platform p G PLF , there is a signal osgn[p] regulating the outgoing train, depending on the availability 
of the exit block. Fig. lb illustrate the common behaviour of all trains. Each train is initially travelling 
outside the station. The train may first arrive at the entry block, provided that it is not occupied. When 
the signal isgn turns green, the train is directed via an in-switch to move in an available platform. For 
some train t, after it moved to platform p, it waits for the light signal of platform p to turn green and then 
moves away from p and onto the exit block. Then the train may depart from the station. 

Trains must never collide in the train station. Also, once a train arrives, it should be eventually 
scheduled to depart from the station. 

(V/7,/2 : TRAIN • (tl^t2/\ loc[tl] ^ Out A loc[t2] ^ Out ) => Ioc[tl] ^ loc[t2]) (3) 

□ ( loc[t] = Entr => 0 (loc[t] = Out) ) (4) 


We consider two versions of TTM that satisfy both Eq. 3 and 4. Fig. 2a presents the TTM interface 
of an abstract version, where monitored and controlled variables are separated. As a result, the abstract 
version contains a single STATION module that: (a) owns all variables; and (b) mixes all events of 
train movement (e.g., event move out in Fig. 3a) and of signal control (e.g., event Ctrl platform signal 
in Fig. 4a). On the other hand, Fig. 2b presents the interface of a refined version, which distinguishes 
between one monitored variable (i.e., occ for the set of occupied platforms) and three controlled variables 
(i.e, isgn for an incoming train, in switch for platform currently connected to the entrance block, and osgn 
for outgoing trains). Consistently, the behaviour of the controller and that of the trains are factored in 
separate events and placed in separate modules. The monitored variable (with modifier in) is owned by 
the STATION module and read-only for the CONTROLLER module. 


module STATION 
interface 

loc : out ARRAY[OPT_BLOCK] 

isgn : out BOOL 

osgn : out ARRAY[BOOL] 

in switch : out BLOCK 


module STATION 
interface 

occ: out ARRAY[BOOL] 

isgn : in BOOL 

osgn : in ARRAY[BOOL] 

inswitch : in BLOCK 

local 

loc : NKRAY[OPT-BLOCK] 


share initialization 

qe : <Queue> 

end 

module CONTROLLER 

interface 

occ : in ARRAY [BOOL] 

isgn : out BOOL 

osgn : out ARRAY [BOOL] 

inswitch : out BLOCK 


(a) Abstract 


(b) Refined: Separate Station & Controller Events 


Figure 2: Train Control System in TTM: Interfaces 


The refined version of TTM changes the representation of the data used by control events. In the ab¬ 
stract version (Fig. 2a), the array variable loc is used to map each train to its current location, constrained 
by type OPTJBLOCK = {Out} U BLOCK where BLOCK = {Entr, Exit} U PLF. All train events (e.g., 
move-out in Fig. 3a) are indexed with the set of trains and update their location accordingly (e.g., loc[t ] := 
Exit). All control events (e.g., Ctrl platform signal in Fig. 4a) query the value of loc in their guards (e.g., 
we write !( | \t: TRAIN @ loc[t] == Exit) to check that the exit block is not occupied). However, a more 
realistic station controller may monitor platforms in the station only, rather than all trains including those 
travelling elsewhere outside the station. Consequently, in the refined version (Fig. 2b), by refactoring loc 
as a local variable in the STATION module (the environment), we hide it from the CONTROLLER. The 
controller then only has access to the monitored variable occ (i.e., the set of occupied platforms) which 
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encodes a coarser grain of information than loc (i.e., locations of all trains). Using the new monitored 
variable occ simplifies guards of controller events (Fig. 4b). Moreover, train events in the environment 
(e.g., Fig. 3b) updates both the local variable loc and the output variable occ. This raises the question 
of whether the CONTROLLER module accesses the monitored variable occ in a way consistent with the 
corresponding events in the abstract model. Therefore, we assert that a block is occupied if and only if it 
corresponds to the location of some train. 

move outit : fair TRAIN) just move out(t : fair IRAIN)[2, *] just 

when call(is_platfonn,loc[t]) && osgn\loc[t ]] when call {is-platform,loc[t]) && osgn[loc[t]] 

do loc[t\ := Exit, osgn\loc\t \] := false end do loc[t] := Exit, occ[/oc[r]] := false, occ[Exit] := true end 

(a) Abstract Version (b) Refined Version 

Figure 3: Train Control System in TTM: the move_out Event in Module STATION 

The two versions of TTMs are different in scheduling the green signals that control the passage from 
the platforms to the exit block. While the abstract model is non-deterministic about the order in which 
trains gain access to the exit block, the concrete model specifies the order uniquely. The signals are 
controlled by event ctrLplatformsignal. In the abstract version (Fig. 4a), the event is indexed by the 
set of trains. When the exit block is not occupied, more than one train located at a platforms may be 
eligible to move on to the exit block. To satisfy Property 4, we declare the index on trains as fair and 
adopt a strong fairness assumption (i.e., compassionate ) on the controller event. That is, a train infinitely 
often qualified to leave the station does so eventually. However, such fairness assumption cannot be 
implemented efficiently. Consequently, in the refined version (Fig. 4b), we use a C# FIFO Queue 3 to 
specify the order of train departure. The reduced non-determinism allows us to remove the fair index on 
trains and weaken the fairness assumption (i.e., the event becomes just). 


ctrLplatform jiignaKp : fair BLOCK) compassionate 
when call (is-platform, p) 

&& (&&p : BLOCK @ call(w platform, p) — > \osgn[]t]) 
&& !(| \f. TRAIN @ loc[t] == Exit ) 

&& (| \t: TRAIN @ loc[t] == p) 
do osgn[p ] := true end 

(a) Abstract Version in module STATION 


ctrLplatformsignal just 
when qe.Count() != 0 
&& \osgn[qe.FirstQ] 

&& \occ[Exit] 

&& occ[qe.FirstQ] 
do osgn[qe.First()\ := true end 

(b) Refined Version in module CONTROLLER 


Figure 4: Train Control System in TTM: Controller Events 


4 Example: Tabular Requirement of a Nuclear Shutdown System 

We illustrate the use of synchronous events on parts of the software requirements of a shutdown system 
for the Darlington Nuclear Generating Station. We present two versions of the system. The first version 
presents a high-level requirements 1111 where the controller responds instantaneously to environment 
changes. We synchronize the environment and controller events to model such instantaneity, and check 

3 Using a C# data object, implementation details of operations such as Enqueue are all encapsulated, resulting in a model 
simpler than one using a native TTM array. 
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it via an invariant property. The refined version illustrates how the response allowance 1121 can be 
incorporated as event time bounds (i.e, the controller responds fast enough to environment changes). We 
decouple the controller from the environment, and check its response via a real-time liveness property. 

Requirements of the shutdown system are described mathematically using tabular expressions (a.k.a. 
function tables) [4]. Figure 5 exemplifies tabular requirements for two units: Neutron OverPower (NOP) 
Parameter Trip (Figure 5a) and Sensor Trips (Figure 5b). In the first column, rows are Boolean conditions 
on monitored variables (i.e., input stimuli). In the second column, the first row names a controlled 
variable (i.e., output response); the remaining rows specify a value for that controlled variable. We use the 
formalism of tabular expressions to check the completeness (i.e., no missing cases from input conditions) 
and the disjointness (i.e., no input conditions satisfied simultaneously) of our requirements [4], 


Result 


Condition 

c .NOPparmtrip 

3i £ 0.. 17 • f NOPsentrip\i] = e Trip 

e.Trip 

Vi € 0.. 17 • f NOPsentrip[i\ = eJVotTrip 

eJNotTrip 


(a) Function Table for NOP Controller 


Result 


Condition 

/JV OPsentrip[i] 

calibrated jiop jsignal[i\ > fJNOPsp 

e.Trip 

fJNOPsp — k NOPhys < calibrated nop signal[i] < f NOPsp 

(/JV OP sen trip[i \) i 

calibrated .nop signal[i] <fJdOPsp — kJNOPhys 

eJVotTrip 


(b) Function Table for NOP sensor i, i € 0.. 17 (monitoring calibratedJiopsignal[i]) 


Figure 5: Tabular Requirement for the Neutron Overpower (NOP) Trip Unit 

The NOP Parameter Trip unit (the NOP controller) depends on 18 instances of the Sensor Trip 
units (the NOP sensors). There are two monitored variables for each NOP sensor i: (1) a floating-point 
calibrated NOP signal value calibrated Jiopsignal\ i ]; and (2) a floating-point set point value/JVORyp. 
The monitored signal is bounded by the two pre-set constants k_NOPLoLimit and k_NOPHlLimit. The 
monitored set point can be one of the four constants: k_NOPLPsp (low-power mode), k_NOPAbn2sp 
(abnormal mode 2), k NOPAbnlsp (abnormal mode 1), and k NOPnormsp (normal mode). 

Each sensor i determines if the monitored signal goes above a safety range (i.e., > fJNOPsp), in 
which case it trips by setting the function variable f_NOPsentrip\i ] to e_Trip. To prevent the value of 
fJNOPsentrip from alternating too often due to signal oscillation, a hysteresis region (or dead band) with 
constant size k_NOPhys is created. The hysteresis region (f_NOPsp — k_NOPhys, f_NOPsp) is an open 
interval. When the monitored signal falls within this region, then the new value of fJNOPsentrip remains 
as that in the previous state, denoted asf_NOPsentrip_ i . The NOP controller is responsible for setting the 
controlled variable c-NOPparmtrip, based on values of fJNOPsentrip[i] from all its dependant sensors. If 
there is at least one sensor that trips, then the NOP parameter trips by setting cJNOPparmtrip to e Trip. 

According to the requirements, the system is initialized in a conservative manner. Each calibrated 
NOP signal is set to its low limit k_NOPLoLimit, but each fJNOPsentrip \ i ] for sensor i and the controlled 
variable c NOPparmtrip are all set to e Trip. As we will see in our specification below (i.e., Equation 6), 
to ensure that the system satisfies the tabular specification in Figure 5, the NOP controller must have 
completed its very first response (denote as predicate -> init-response). 

The requirements model in Figure 5 uses a finite state machine, with an arbitrarily small clock tick, 
that describes an idealized behaviour. At each time tick t, monitored and controlled variables are updated 
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instantaneously. State data such as f_NOPsentrip_ x are stored and used for the next state. However, 
to make such requirements implementable, some allowance on the controller’s response must be pro¬ 
vided [12]. As a result, we present two versions of the NOP system in TTM: (1) an abstract version with 
plant and controller taking synchronized actions; and (2) a refined version with the response allowance 
incorporated as time bounds of the environment and controller events. The refined version allows us 
to assert timed response properties (e.g., once the monitored signal goes above the safety range, the 
controller trips within 2 ticks of the clock). 

Abstraction of Input Signal Values. The TTM tool, like other model checking tools, cannot handle 
the real-valued monitored variables f_NOPsp and calibratedjiop_signal[i]. Instead, based on the given 
constants mentioned above, we partition the infinite domains of these two monitored variables into dis¬ 
joint intervals. First, the four possible constant values for f_NOPsp have a fixed order and are bounded 
by constant low and high limits of the calibrated NOP signal. More precisely, we have 6 boundary cases 
to consider: k_NOPLoLimit < kJSOPLPsp < k_NOPAbn2sp < k_NOPAbnlsp < k_NOPnormsp < k_NOPI / iLimit. 
Second, each of the four possible set points has an associated hysteresis band, whose lower boundary 
is calculated by subtracting the constant band size k_NOPliys, resulting in 4 additional boundaries 4 to 
consider: (a) kJVOPLPsp — kJNOPhys\ (b) kJVOPAbn2sp — kJVOPhys', (c) kJNOPAbnlsp — k-NOPhys; 
and (d) k_NOPnormsp — kJVOPhys. Consequently, we have 10 boundary cases and 9 in-between cases 
(e.g., kJVOPLoLimit < signal < kJVOPLPsp) to consider. Accordingly, we construct a finite integer set 
caljiop that covers all the 19 intervals. 

For the purpose of modelling and verifying the NOP controller and sensors in TTM, we parameterize 
the system by a positive integer N denoting the number of dependant sensors. 

Version 1: Synchronizing Plant and Controller. We first present an abstract version of the model that 
couples the NOP controller and its plant by executing their actions synchronously. Figure 6 illustrates 
the structure of synchronization. The dashed box in Figure 6 indicates the set of synchronized modules 
instances: plant p, controller nop, and 18 sensors sensor J (/GO.. 17). 



Figure 6: Neutron Overpower (NOP): Abstract Version - Synchronized Plant and Controller 

Figure 8 (p. 95) presents the complete 5 TTM listing of the NOP unit as described above. The gen¬ 
erate event of the plant non-deterministically updates the value of a global array that is shared with 
sensors attached to the NOP controller. The update is performed via the demonic assignment cali¬ 
brated jiop.signals :: ARRAY\calJiop\(N) (Lines 5 - 6). The NOP controller module (Lines 8 - 26) 
depends on two module instances (Lines 9-11). First, the controller depends on a plant p that generates 

4 Value of (a) is still greater than k_NOPLoLimit, and similarly value of (d) is still smaller than k_NOPHiLimit. 

5 For clarity, we present a version with one monitoring sensor. The full version with 18 sensors involves just declaring and 
instantiating additional dependent sensors. We also exclude definitions of constants and assertions. 
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an array of calibrated NOP signals (specified by the out array argument calibrated_nop.signal at Lines 
4 and 47). Second, the controller depends on a sensor sensor JO that monitors a particular signal value 
(specified by the in argument calibratedjiop_signal[ 0] at Lines 30 and 48) and provides feedback (spec¬ 
ified by the share argument fJNOPsentrip[0] at Line 31 and 48) for the central NOP controller to make 
a final decision (specified by the out argument cJNOPparmtrip at Lines 14 and 49). 

Actions of the respond events of the NOP controller (Lines 19 - 24) and of its dependent sensors 
(Lines 36 - 43) correspond to the tabular requirements (Figure 5a and Figure 5b, respectively). We use 
primed variables in these actions to specify the intended flow of actions. Actions of the NOP sensor 
reference f_NOP’ and calibratedjiop.signal _/’ (Lines 37, 39, and 41) to indicate, that only after the 
instance p (in the same synchronous set) has written to these two variables can they be used to calculate 
the new value of fJNOPsentrip\i\. Similarly, actions of the NOP controller reference/ NOPsentrip’\j\ 
(Lines 20 and 22) to indicate, that only after all sensor instances have written to this array can it be used 
to calculate the new value of cJNOPparmtrip. 

We require that the respond event of the NOP controller, the respond events of its dependent sensors, 
and the generate event of the plant, are always executed synchronously (as a single transition). In declar¬ 
ing the controller event respond, we use a sync ... as ... clause to specify the events to be included in 
the synchronous set. When instantiating the NOP controller, we use a with ... end clause to bind its 
dependent plant and sensor instances (Line 49). Finally, we rename the synchronized plant, controller, 
and sensor instances for references in assertions (Line 50). 

We check two invariant properties on this abstract version of NOP. First, as all dependent sensors 
have written to the shared array fJNOPsentrip, the NOP controller responds instantaneously. 


I_l f ( 3i : 0 ..N • fJNOPsentrip[i\ = eJTrip ) => cJNOPparmtrip = eJTrip 

y A (Vi: 0..N • fJVOPsentrip [t] = eJNotTrip ) => cJNOPpanntrip = eJNotTrip 

Second, since all actions of the plant, the NOP controller, and sensors are synchronized together, we can 
assert that the controlled variable cJNOPparmtrip is updated as soon as the plant has updated the two 
monitored variables fJNOPsp and fJNOPsentrip. 

/ / — init_respon.se 

n A fJNOPsp = kJNOPLPsp 

~ ( A kJNOPLPsp < calibrated nop signal[0\ < k CalNOPHiLimit 

y => cJNOPparmtrip = eJTrip 

However, the satisfaction of Equation 6 is an idealized behaviour without the realistic concern of 
some allowance on the controller’s response H21 . That is, we shall instead allow the state predicate 
cJNOPparmtrip = eJTrip to be established within a bounded delay. 

Version 2: Separating Plant and Controller. We refine the TTM of NOP in Figure 8 by decoupling 
actions of the controller 6 and its plant. Figure 7 illustrates the refined structure of synchronization: the 
plant instance p is no longer synchronized with the controller. Consequently, the plant event generate 
and the synchronous controller event respond are interleaved. 

The resulting system would fail to satisfy Equation 6, as we introduce some allowance on the re¬ 
sponse time (termed response allowance in [12]) of the NOP controller to environment changes. On 

6 In the NOP controller, actions of the NOP parameter trip unit and sensor units remain synchronized. 








Wang, Ostroff, and Hudon 


93 



Figure 7: Neutron Overpower (NOP): Refined Version - Separate Plant and Controller 


the other hand, as we still consider the controller’s response actions, once initiated, take effect instanta¬ 
neously, the resulting system should still satisfy Equation 5. 

We apply the following changes to produce the refined TTM (Figure 8). First, in module PLANT, 
we revise time bounds of the generate event to [2, *], which encodes the assumption that the controller 
(whose respond event has time bounds [1, 1]) responds fast enough to the environment changes. Second, 
in module NOP, we remove the declaration of p : PLANT as a dependent instance (Fine 10). We also 
remove the declaration of p.generate as an event to be synchronized with the respond event (Fine 17). 
Third, in creating the instance nop of module NOP, as it no longer depends on a PLANT instance, we 
remove the binding statement (Fine 49), i.e., env := env. Fourth, in renaming the synchronous instance, 
we remove the plant instance (Fine 50), i.e., controller ::= sensor JO || nop. Finally, we add the plant 
instance into the composition (Fine 52), i.e., system = env || controller. 

By declaring a timer t and adding a start t clause to the generate event in module PLANT (Fine 6), 
we can satisfy the following real-time response property: 


/ / f-NOPsp = kMOPLPsp 

_ A kJVOPLPsp < calibratedjiop_signal[ 0] < k_CalNOPHiLimit 

U \A t =0 

y => mono(t) U ( cJStOPparmtrip = e -TripAt < 2 ) 

As soon as the set point value and monitored signal value are updated by the plant, the controller produces 
the proper response within two ticks of the clock. Before the controller responds, timer t must not be 
inteiTupted (i.e., reset by other events), so as not to provide an inaccurate estimate. 

5 Discussion 

Our new TTM notations facilitate the formal validation of cyber-physical system requirements. In the 
train control system (Sec. 3), the indexing construct allows us to select a specific actor (e.g., a train, a 
process, etc.) and specify a temporal property for that actor. Synchronous events, together with primed 
variables, allow us to check (real-time) response properties of the tabular requirements of a nuclear 
shutdown system (Sec. 4). 

To our knowledge, the introduced notations of indexed events and synchronous events (and its com¬ 
bination with primed variables) are novel. For synchronous events, the conventional Communicating 
Sequential Processes (CSP) [7] and its tool [2] support multi-way synchronization by matching event 
names in parallel compositions. However, the conventional CSP does not allow processes to modify a 
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shared state. Instead, the system state can only be managed as parameters of recursive processes, making 
it impossible to synchronize events that denote different parts of simultaneous updates. The notations of 
un-timed CSP# and the stateful timed CSP (extended with real-time process operators such as time-out, 
deadline, etc.) [8] allow events to be attached with state updates. However, their semantics and tool sup¬ 
port do not allow events that are attached with updates to be synchronized. The UPPAAL model checker 
and its language of timed automata [5] support the notion of broadcast channel for synchronizing multi¬ 
ple state-updating transitions (one sender and multiple receivers). However, the RHS of assignments can 
only reference values evaluated at the pre-state. There is no mechanism, such as the notion of primed 
variables supported in TTM, for specifying the intended data flow. 

For indexed events, the verification tool support for both conventional CSP [7] and UPPAAL [5] does 
not allow for fairness assumptions. For UPAAL, it is likely to manually construct an observer, but this is 
likely to result in convoluted encoding in larger systems and thus is prone to errors. On the other hand, 
the PAT tool allows users to choose fairness assumptions at the event, process, or global level [9] for 
verifying the un-timed CSP# and stateful timed CSP [8]. However, our notion of indexed events are of 
finer-grained for imposing fairness assumptions, as we allow the declaration of event indices as fair. 
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1 module PLANT /* Template for Nuclear Reactor */ 

2 interface 

3 fJNOPsp : out INT = kJNOPLPsp 

4 calibratedjiopsignal: out AKRAY[caI_nop](NUM_SENSORS) = [k.CalNOPLoLimit ( NUM_SENSORS )] 

5 events generate[\, 1] 

6 do calibrated nop signal :: ARRAYfcaZ nop](NUM SENSORS)./ NOPsp := kJNOPLPsp end 

7 end 

8 module NOP /* Template for Neutron Overpower Controller */ 

9 depends 

10 env : PLANT 

11 sensor.0 : NOPSENSOR 

12 interface 

13 fJNOPsentrip : share ARKAY[y_trip](NUM_SENSORS) /* shared, but read only */ 

14 c.NO Pparmtrip : out yjrip - e.Trip 

15 local after_in.it.response : BOOL = false 

16 events 

17 respond[ 1, 1] sync env.generate, sensor.0.respond as respond 

18 do 

19 afterJnit.response := true, 

20 if (| | j: 0..(NUM_SENSORS— 1) @ fPNOP sent rip' [/] == e.Trip) then 

21 c.NOPparmtrip := e.Trip 

22 elseif (&& k: 0..(NUMJiENSORS—l) @ fJVOPsentrip’[k\ == ePNotTrip ) then 

23 c NOPparmtrip := eJdotTrip 

24 else skip fi 

25 end 

26 end 

27 module NOPJiENSOR /* Template for Sensors */ 

28 interface 

29 fJSIOPsp : in INT 

30 calibrated_nop.signal J : in cal_nop 

31 fJdOPsentrip.i : share y.trip /* shared, but write only */ 

32 local fPNOPsentripA.old : yjrip = e.Trip 

33 events 

34 respond[ 1, 1] 

35 do 

36 fJS/OPsentrip.i.old’ =fJdOPsentrip_i, 

37 if fJSIOPsp’ <= calibrated nop signal t then 

38 fJgOPsentrip.i := e.Trip 

39 elseif {fJdOPsp ’ — kJVOPliys < calibrated Jiop .signal _V ) && (calibrated Jiop .signal _i <fJVOPsp’) then 

40 fPNOPsentrip.i ■—fJdOPsentrip.i.old 

41 elseif calibrated Jiop .signal.i <= fJSIOPsp’ — kJdOPhys then 

42 fPNOPsentrip.i := eJNotTrip 

43 else skip fi 

44 end 

45 end 

46 instances 

47 env = PLANT (out fJSIOPsp, out calibrated .nop signal) 

48 sensor.O = NOPJsENSOR(mfJdOPsp, in calibrated.nop.signal[0\, share fJgOPsentrip[d\) 

49 nop = NOP(share fLNOPsentrip. out cJdOPparmtrip) with env := env, sensor.O := sensor.O end 

50 sys ::= env |i sensor.O || nop /* named synchronous instance */ 

51 end 

52 composition system = sys end 


Figure 8: Requirement of NOP in TTM: Synchronized Plant and Controller 



